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DEVICF. DRIVER CONRGURATinN !N A rOM PUTRR SYSTF.M 

BACKGROUND OF THE INVENTION 
1. Field of (he Invention 
5 The present inveniion pertains to the field of computer systems. 

Specifically, the present invention relates to computer systems supporting 
an interface for removable system resources and the controJ of device 
drivers related thereto. 

10 2. Prior Art 

It is becoming increasingly more important to design and build 
computer systems that can be dynamically configured without powering 
down the computer system or requiring the operating system program 
logic to be reset or bootstrap initialized. Dynamic configuration includes 
\5 the ability to add or remove system resources or special feature capabilities 
while a computer system is operating. These system resources and special 
features include expansion memory boards, parallel or serial input/output 
(I/O) ports, read only memory (ROM) or flash memory expansion boards, 
computer network interface cards, modem cards, smart cards, or other 

20 removable system resources or special feature mechanisms. 

Such removable system resources and special features are often 
implemented in the prior art using removable electronic feature cards 
adhering to the Personal Computer Memory Card International Association 
(PCMCIA), Sunnyvale, Ca., Release 2,0 standard, lliese PCMCIA feature 

25 cards generally comprise electronic microcircuits within a thin housing 
including a detachable multiple conductor interface with which the feature 
card may be removably inserted into a slot in a computer housing. Once 
inserted, a feature card is accessible to and used by the processor in the 
computer system. The use of feature cards allows a computer user to select 

30 specific features or resources from a variety of feature cards offered by a 
computer vendor. In this way, the computer user achieves the desired level 
of functionality without being required to purchase unnecessary resources 
or computer system capabilities. The overall cost of the computer system 
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for a specific applicaiion is thereby opiimized. The use of removable 
feature cards is particularly significant for portable computers or lap top 
computers where space constraints increase the need for system resource 
optimization. Tlie design and use of hardware devices under the PCMCIA 
standard are well known in the art. It will be apparent to those skilled in 
the art that other implementations of removable system resources are 
possible. 

Virtually all computer systems operate with some sort of operating 
system or software processing logic. The use of an operating system in a 
computer system is well-known in the art. The operating system is 
responsible for managing the processing and transfer of information 
between various system resources. One well known technique for managing 
these resources is the use of device drivers. Device drivers are software 
modules comprising processing logic for controlling the low level or 
device specific components of a particular computer system resource. For 
example, a device driver may be used for controlling a magnetic disk drive 
device coupled to a computer system. In this example, the device driver 
uould control the various hardware specific registers, latches, signals, or 
other components of the magnetic disk drive device. Similarly, other 
20 computer system resources such as serial or parallel input/output (I/O) 
ports, modem devices, computer network interface devices, or memory 
expansion boards are controlled by device drivers. 

In conventional computer systems, device drivers are typically 
loaded into random access memory (RAM) during bootstrap initialization 
of the computer system. Many prior art computer systems require that 
device drivers be loaded at initialization time in order for random access 
memory to be allocated properly. Depending upon the complexity of the 
device controlled by the device driver, the device driver itself may be 
relatively small or a very large device driver that consumes many 
thousands of bytes of random access memory. Thus, many prior art 
systems require that a full system configuration of resources be installed 
and available at bootstrap initialization time. If system resources or 
interfaces are subsequently added or removed from the system, the 



25 



30 



access to a new configuration of system resources. Thus, prior an 
computer systems cannot be readily reconfigured to a new arrangement of 
system resources. 

Because prior an systems typically require that a full system 
10 configuration of resources be established at initialization time, the tendency 
exists for any or all system resources that may conceivably be used while a 
computer system is powered up to be installed during the initialization 
process. This tendency leads to the installation of resources that are never 
used during a computing session. The loading and installation of unused 

15 system resources increases the time required for bootstrap initializing the 
system and reduces the available random access memory (RAM), because 
of the RAM space required by unused device drivers. It is, therefore, 
important to install in a computer system only those device drivers actually 
needed during a computing session. In some cases, it may not be possible 

20 to load all of the device drivers necessary because of the random access 
memory storage constraints. 

Some computer systems in the prior art provide means for 
interfacing with removable electronic feature cards. In order to mitigate 
the disadvantages described above, some of these computer systems store 

25 associated device drivers on the removable electronic feature card itself. 
In tliis way, random access memory space within the computer system does 
not need to be allocated for storage of the device driver. Moreover, 
processing time during initialization is not consumed by having to load the 
device driver into random access memory. Systems that configure device 

30 drivers on the removable feature cards have the advantage of optimizing 
memory allocation requirements within the computer system. 

Systems that configure device drivers on removable feature cards, 
however, have several imponant disadvantages. First, if a feature card is 
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removed from ihe computer system, the device driver controlling the 
operation of the feature card becomes inaccessible to the computer system, 
m most cases, the computer system requires access to a device driver in 
order to properly temiinate the operation of the device prior to removal of 
the feature card. Typically, the computer system does not have sufficient 
,ime to access the device driver prior to removal of the feature card. 
Thus, system errors often result from an improperiy terminated system 

resource. . -.k 

Other computer systems having means for interfacmg with 
removable electronic feature cards, provide a very limited capability for 
responding to insertion or removal of feature cards during post 
initialization operation of the computer system. Some computer systems do 
not recognize system resources connected to the computer system after the 
bootstrap initialization process has been completed. Other computer 
systems suspend or freeze the operation of the computer system if a system 
resource is removed after initialization is complete. Still other computer 
systems require that the system be powered down or the bootstrap 
initialization process be reinitiated if a new connguration of system 

resources is desired. 

Thus, a belter means for dynamically configuring system resources 

in a computer system is needed. 



-5- 

SUMM AR Y OF Tl !Ii INVRNmON 

Tlie present invention is a computer system having dynamic device 
driver configuration for removable system resources. The computer 
system comprises a processor* a system memory and an interface for 
5 receiving removable system resources. These system resources and special 
features include expansion memory boards, parallel or serial input/output 
(I/O) ports, read only memory (ROM) or flash memory expansion boards, 
computer network interface cards, modem cards, smart cards, or other 
removable system resources or special feature mechanisms (generally 
10 denoted feature cards or cards). 

A feature card includes a card memory area. The card memory area 
includes software for controlling the remaining card specific functionality. 
This software within the card memory area, including both data and 
processing logic, includes a device driver for controlling the feature card. 
15 In order to avoid the problems encountered in the prior art, the 

feature card device driver of the present invention is separated into two 
parts: 1) a full device driver portion, and 2) a stub device driver portion. 
The full device driver provides all of the device driver functionality 
necessary to control each and every function of the feature card. The 
20 device driver stub is a small compact portion of processing logic associated 
with the full device driver, but mainly responsible for linking the full 
device driver with operating system software located in the computer 
system. 

The card memory area comprises a device driver information block 
25 (DDIB) header, a device driver stub code image, and full device driver 
code. The device driver information block header comprises information 
used for linking the device driver with other device drivers and computer 
system processing logic. The device driver stub code image comprises a 
compact portion of processing logic and data that is copied into computer 
30 system memory upon insertion of a feature card into the computer system. 
Tlie full device driver code remains card resident. 

Upon insertion of a card into the computer system, the device driver 
stub code image is read from the card memory area and transferred into an 
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area of computer system mcmor>\ Hie device driver siub code is then 
executed by the processor of ihe computer system from computer system 
random access memory. Conversely, the full device driver code is not 
transferred to the computer system random access memory; rather, the fuU 
5 device driver is executed while stiU resident on the card. Upon execution, 
the device driver stub enables access to the full card resident device driver 
and allows memory mapping to the full device driver. The full device 
driver may then be activated by the processor. 

The DDIB header comprises a set of infomiaiion for linking the card 
10 device driver in a linked list with other device drivers and with the 
operating system logic executing within the computer system. By 
traversing the linked list, a particular device driver may be located. Upon 
insertion of a card, the linked list of device drivers is traversed lo 
determine whether the device driver stub already resides in said computer 
15 system memory. If so, the operation of copying the device driver stub into 
computer system memory is prevented from occurring. As a card is 
inserted, a card insertion flag is set to indicate the removable system 
resource is coupled to llie computer system. 

When a card is removed from the computer system, the linked list of 
20 device driver stubs is traversed to find all device driver stubs associated 
with the removed card. Each associated device driver stub is executed. The 
device driver stub disables access to the removed card by disallowing 
memory mapping to the removed card. The device driver stub is unlinked 
from the linked list of device driver stubs and the card insertion flag is 
25 reset to indicate that the removable system resource has been decoupled 
from the computer system. 

It is, therefore, an object of the present invention lo provide a 
computer system in which system resources may be added or removed 
prior lo or following bootstrap initialization of the computer system. It is 
30 a further object of the present invention to provide a computer system 
wherein system resources may be reconfigured without powering down the 
computer system. It is a further object of the present invention to provide 
a computer system wherein system r^.sources may be reconfigured without 



reinitiaiing the bootstrap iniiializaiion process. It is a further object of the 
present invention to provide a computer system wherein unused system 
resource device drivers do not need to be loaded into the random access 
memory of the computer system. It is a further object of the present 
5 invention lo provide a computer system wherein the full system 
configuration may not necessarily be known at bootstrap initialization time. 
It is a funher object of the present invention to provide a computer system 
having an interface for receiving removable electronic feature cards that 
may be inserted or removed at any time during operation of the computer 
JO system. 

These and other objects of the present invention will become 
apparent as presented and described in the following description of the 
preferred embodiment. 
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RPTPF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram of ihe archiiccture of a computer system 
in which ihe present invention operates. 

Figure 2 is an example of a computer housing containing a plurality 
5 of feature card insertion slots. 

Figure 3 is a block diagram of the contents of a removable electronic 

feature card. 

Figure 4 illustrates the content of the Device Driver Information 
Block Header. 

10 Figure 5. illustrates the content of computer system memory as 

related to the content of the feature card memory. 

Figure 6a illustrates the content of the Device Driver Stub RAM 

Area. 

Figure 6b illustrates the content of a stub block. 
15 Figure 6c illustrates the content of a stub header. 

Figure 6d illustrates the content of the stub data area. 
Figures 7-13 are flow charts illustrating the processing logic of the 
preferred embodiment. 



DRTAILKD DF.SCRIPTION OFTHF PRFFFRRFp EMBODIMFNT 

llie present invention is a computer system having a method and 
means for dynamically configuring device drivers of removable system 
resources. In the following description, numerous specific details are set 
5 forth in order to provide a thorough understanding of the present 
invention. However, it will be apparent to one of ordinary skill in the art 
that iJiese specific details need not be used to practice the present invention. 
In other circumstances, well known structures, circuits, and interfaces have 
not been sliown in detail in order not to obscure unnecessarily the present 
10 invention. 

Referring now to Figure I, a block diagram of the computer system 
in which the present invention operates is illustrated. It wiU be apparent to 
those of ordinary skill in the art. however, that alternative computer 
system architectures may be employed. In general, such computer systems 
15 as illustrated by Figure I comprise a bus 100 for communicating 
information, a processor 101 coupled with the bus 100 for processing 
information, and a random access memory device 102 coupled with the bus 
100 for storing information and instructions for processor 101. The 
processing logic of the present invention is typically stored in a device such 
20 as random access memory 102 and executed therefrom by processor 101. 
In addition, a typical computer system may optionally include other system 
resources including a read only memory device 103 coupled with the bus 
100, an input device 104 such as an alphanumeric input device or a cursor 
control device coupled to the bus 100 for communicating infomiation and 
25 command selections to the processor 101. a display device 105 such as a 
video display terminal or a liquid crystal display device coupled to the bus 
ICQ for displaying information to a computer user, a data storage device 
106 such as a magnetic disk and disk drive coupled with the bus 100 for 
storing infomnation and instructions, an output device 107 such as a printer 
30 or facsimile apparatus coupled to the bus 100 for communicating 
information to a destination external to the computer system, and a 
removable electronic feature card interface 108 for electrically removably 
coupling an electronic circuit card to bus 100. 
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Removable feature cards which may be removably insened into 
inierface 108 generally comprise electronic microcircuils within a thin 
housing including a detachable muliiple connector interface with which the 
feature card may be removably inserted into a slot in a computer system 
housing. In the preferred embodiment, the feature cards and feature card 
interface 108 used with the present invention adhere to the PCMCIA 
release 2.0 standard for electronic feature cards. Feature cards of this 
form are well known to those of ordinary skill in the art 

Referring now to Figure 2, an illustration of a computer system 
housing having a plurality of feature card interfaces (203. 205, 207. and 
209) is illustrated. As shown, feature cards 211 and 213 may be 
removably inserted and thereby electrically coupled to an interface 108 
within the computer system. This feature card structure facilitates the 
convenient insertion and/or removal of feature cards during the course of a 
computing session. 

Referring now to Figure 3. the structure of a typical feature card 
301 is illustrated. Feature card 301 includes an interface 302 with which 
the feature card 301 may be removably electrically coupled to a computer 
system. Feature card 301 also includes a card memory area 303. Card 
memory area 303 includes software for controlling the remaining card 
specific functionality. This software within card memory area 303, 
including both data and processing logic, includes a device driver for 
controlling the operation of the feature card. 

As described above, it is convenient to store the device driver for a 
feature card on the feature card itself. Using this technique. RAM space 
within the computer system does not need to be provided for the card 
device driver and processing time is not consumed in transferring a device 
driver from the card lo computer system RAM. Maintaining the card 
device driver on the card itself also achieves the advantage of assuring that 
the device driver is always compatible wiUi the card specific functionality. 
There is less chance for a mismatch between the device driver stored in the 
computer system and the card specific functionality provided on the card. 



area is on ilie feaiure card. Knowing the location and size of the code and 
data areas for the device driver stub, operating system logic within ihe 
computer system may transfer the device driver stub code and data areas 
from the featurc card into computer system random access memory. 
5 Referring now to Figure 5, a ponion of computer system memory 

501 residing within random access memory 102 is illustrated. Computer 
system memory portion 501 comprises device driver loader 503, device 
driver stub RAM area 505. and PCMCIA socket services 507. Device 
driver loader 503 comprises processing logic for loading and dispatching 
10 the appropriate device driver on initialization of the computer system and 
when a card is inserted or removed (i.e. a card insenion or removal event) 
from the computer system. The details of the processing performed by the 
device driver loader 503 of the preferred embodimem is described in more 
detail in connection with the flow charts of Figures 7 and 8. Device driver 
5 stub RAM area 505 comprises a memory area used for the storage of 
device driver stubs that are either loaded during computer system 
initialization time or loaded upon the insertion of a card imo the computer 
system. The content of device driver stub RAM area 505 is described in 
more detail in connection with Figures 6a and 6b. PCMCIA socket 
seivices 507 comprises processing logic for handling low level control of 
card insertion and removal events. Processing logic within PCMCIA 
socket services 507 receives interrupts upon the detection of a card 
insertion or removal event. Processing logic corresponding to the function 
carried out by PCMCIA socket services 507 is well known to those of 
25 ordinary skill in the an. 

Also illustrated in Figure 5 is card memory area 303 as described 
above in connection with Figure 3. Card memory area 303 comprises 
device driver information block (DDIB) header 305. device driver stub 
code image 307, and full device driver code 309. 

Upon a card insertion event. PCMCIA socket services 507 receives 
and interrupt and initially responds to the card event. PCMCIA socket 
services 507 activates device driver loader 503 as indicated by line 603 in 
Figure 5. Upon activation of device driver loader 503. PCMCIA socket 



20 
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scn'ices 507 provides device driver loader 503 with an ideniincalion of the 
socket adapter and socket for which the card event interrupt was received. 
Device driver loader 503 then accesses the device driver information block 
(DDIB) header 305 on the newly insened card as indicated by line 605. By 
5 accessing DDIB header 305, device driver loader 503 gains access to ihe 
card information described above in connection with Figure 4. 
Specifically, device driver loader 503 may read the device driver stub 
unique identification 407, device driver stub code offset 421, device driver 
stub code length 423, device driver stub data offset 425, and device driver 

JO stub data length 427. Using this information, device driver loader 503 
determines where in card memory area 303 the device driver stub code 
image 307 resides. Once the location and size of device driver stub code 
image 307 is deicmiined as indicated by line 607. device driver loader 503 
copies the contents of device driver stub code image 307 from card 

15 memory area 303 into a portion of device driver stub RAM area 505 as 
indicated by line 609 in Figure 5. The device driver stub code image 307 
is written into device driver stub RAM area 505 and linked into a linked 
list of device driver stubs maintained by device driver loader 503, The 
manner in which the device driver stubs are linked by device driver loader 

20 503 is described in connection with Figures 6a and 6b. 

Referring now to Figure 6a, the device driver stub RAM area 505 is 
illustrated. Device driver stub RAM area 505 comprises memory storage 
area for a plurality of device driver stub blocks. By way of example, 
Figure 6a illustrates stub 1 block 510, stub 2 block 512, stub 3 block 514, 

23 and stub n block 516. It will be apparent to those skilled in the art that any 
number of device driver stub blocks from zero to n may reside within 
device driver stub RAM area 505. It will be also apparent to those skilled 
in the art that the number of stub blocks within device driver stub RAM 
area 505 dynamically changes throughout the usage of ihe computer 

30 system. Thus, the device driver stubs do not need to be fixed in memory at 
bootstrap initialization time. It should also be noted that the relative size or 
number of memory locations required by each device driver stub block is 
relatively small in comparison to the full device driver code for controlling 



stub block provides tne opporiunii) lo siore a largc nuniucj ui uaicrcm 
device driver stubs within device driver stub RAM area 505. 

The device driver stub blocks within device driver stub RAM area 

5 505 are each composed of three components. Referring now to Figure 6b, 
the three components of each stub block of device driver stub RAM area 
505 is illustrated. Each stub block comprises a stub header 540, stub data 
542. and stub code 544. Stub header 540 is used mainly by operating 
system logic that controls the operation of the computer system. 

10 Referring now to Figure 6c, the content of stub header 540 for each 

stub block is illustrated. Stub header 540 comprises device driver linkage 
information 630, device driver attribute information 632, device driver 
strategy offset 634, device driver interrupt offset 636, and device driver 
units and name 638. The computer system memory 102 resident device 

15 driver information 630, 632. 634, 636, and 638 of the stub header 540 
corresponds to the device driver information 411, 413, 415, 417, and 419 
of the card resident DDIB header. The DDIB device driver information is 
transferred to the stub header 540 when a stub device driver is loaded. 

Device driver linkage information 630, device driver attribute 

20 information 632, and device driver units and name 638 comprise device 
driver identification and linking infomiation used by the operating system 
to identify and link with the corresponding device driver. Device driver 
linkage information 630 is used by the operating system to create a 
forward linked list of device drivers as illustrated by lines 519 in Figure 

25 6a. Using the device driver linkage infonnation 630, the operating system 
518 may access each device driver in the linked list by traversing down the 
list using the device driver linkage information of each device driver stub 
block until the last device driver stub block points back to the operating 
system 518. Stub header 540 also includes a device driver strategy offset 

30 634 and a device driver interrupt offset 636 which are used to identify the 
entry point to stub code 544 as illustrated by line 546 in Figure 6b. 

Referring now to Figure 6d. the content of stub data 542 is 
illustrated. Stub data 542 comprises pointers 660 and 662 that arc used by 
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a,vicc arivcr .o,dc, 503 fc, crea.ms > fo,w„d and b3ckwa,^hnU.d 1,« 
of acvice driver s>.b blocks wi.hin device driver s.ub RAM ar« 505. 
Poimer 660 U a po,n.er .o .he previous device driver ...b blocK .n ,he 
linked H«. Pointer 662 is a pointer ,0 *e nex, device driver s.ub block m 
,he linked lis., n-is doubly linked lis. s.ruc.ure is illus.ra.ed in Figure 6a 

"""1^1.8 .0 Figure 6a. device driver loader 503 con.ains a poimer 
,„ ,be firs, device driver s.ub block 510 in .1« linked Us.. n.e poin«r 662 
0, s.ub 1 block 510 poims ,o s,ub 2 block 5.2. Similarly, pom.er 660 of 
„„b 1 block 510 polms back ,0 device driver loader 503 In a s,n,,la, 
.nanner. poin.ers 660 and 662 of eacb device driver ' 
poin. ,0 d,e previous and ne.. device driver s.ub in .he Unked .s.^ Tl^us 
L device driver s.ubs are forward and backward linked in a hnked • • 
T1,e las. device driver s.ub block in *e Unked Us. (i.e.. sh>b n block 516). 
, poims back .0 device driver loader 503 .o comple,e 0,e doubly linked l,s.. 

Referring again .0 Figure 6d. s.ub da>, 542 also compnses an 
3dap.er iden.ifica.ion 664 and a socke. iden.ir.ca.icn 666. Adap.e, 
iden.inca.ion 664 and sockel idemir.ca.ion 666 uniquely idem.fy .he 
con,pu.er sys.en, hardware in.erface .Lh which .he device driver s«b .s 
» a.soL,ed. Device driver s.ub unique id=n.inca,ion 668. which ,s d,e same 
iden.inca,lon as .he fea.ure card residen. device driver s.ub un.que 
aen,ifica,ion 40, lUus.ra.ed in Figu. 4, uniquely iden.mes , e dev,„ 
ariver s.ub associa.ed wi.h .he fea.ure card. Card lnsen,on nag 672 .s used 
,„ retain an indica.ion of whe.her .he card associa.ed wi.h .he dev,ce dnver 
„ s,ub is inserred or removed. Drive, specific da,a area 674 is a memory 
area alloced for use by .he device driver s.ub for s.o,age of i« own dau. 

Referring now .o Figures 7 .brovgh 13, nowcharts illuslraimg die 
processing logic used by .he preferred embodimen. a„ illus«.ed I. ^11 
be apparen. .o O,ose skilled in .he an *a. .he processing log,c descnbed 
30 herein may be exccu.ed by processor 10. of the computer sys.em^ ^ 

Referring now to Figure 7. 0.e pmcesslng logic assoca.ed w,U. *e 
device driver loader 701 is il.us.ra.ed. Device driv r loader logic 70. 
rresponds to device driver loader 503 illustrated in F.gures 5 and 6a. 



. .u....,ng ,og,c Marung ar bubble 701 niay be activated by the operating 

SVSIem fli hnntciran in«f i^i:^..: _. 

" "«c computer system. Upon activation 
of the device driver loader, a card event se^ice routine is registered with 
the operating system in processing block 702. Means for registering a 
5 service routine with the operating system is well-known in the an. This 
card event service routine is activated upon a card insenion or removal 
event. Device driver stub RAM area 505 is allocated in processing block 
703. A prcdctemiined quantity of random access memory 102 is allocated 
for the storage of device driver stubs in device driver stub RAM area 505. 
10 A set of commonly used device drivers may optionally be preloaded into 
the device driver stub RAM area 505 during initialization time in 
processing block 705. Hiese initially loaded device drivers may be stored 
on a mass storage device and transferred from there into device driver stub 
RAM area 505. Next, the hardware interfaces are queried to determine the 
15 idemity and address of card socket adapters that are comiected and 
available for use within the computer system. In an alternative 
embodiment, a predetermined list of card socket adapters may be provided 
and obtained by the device driver loader in processing block 707. In a 
similar mamier. the address or identity of each of the card sockets within 
20 each card socket adapter is detemiined in processing block 709. If any 
feature cards are currently installed in any of the available sockets of the 
computer system, the identity or address of the installed cards is obtained 
in processing block 711. The device driver loader now has a list of card 
socket adapters, a list of card sockets, and a list of currently installed 
25 feature cards. An index parameter is initialized to poim to the first of the 
currently installed cards in the list of installed cards in processing block 
713. A subfunction called "Card Insenion Processing" is then activated in 
processing block 715 to install the device driver stub for the currently 
indexed card. Device driver loader processing continues at the bubble 
30 labelled A as illustrated in Figure 8. 

Referring now to Figure 8. the processing for the device driver 
loader continues at the bubble labeled A. As the list of currently installed 
cards is processed, decision block 1017 is executed to determine if all cards 
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have been processed. Once .11 of the cards in the list of installed cards have 
been processed, processing path 1021 is taken to temiinaiion bubble 1027 
where processing for the device driver loader terminates. If each of the 
installed cards in the list of installed cards have not yet been processed, 
processing path 1019 is taken lo processing block 1023 where the index 
into the list of installed cards is advanced to point to the next installed card 
and processing continues at the bubble labelled G as illustrated in Figure 7. 
At tlie bubble labelled G. the card insertion processing subfunction is again 
activated for the newly indexed installed card. 

Referring now to Figure 9, the processing for a card event service 
routine 1101 is illustrated. Card event service routine 1101 is a software 
routine registered with the operating system at bootstrap initialiMiion of 
the computer system. Card event service routine 1101 is activated when a 
hardware event is detected by the computer system upon the insertion or 
removal of a feature card in any socket provided by the computer system. 
Upon activation of card event service routine 1101. the identity of the card 
socket adapter and the card socket corresponding to the hardware event is 
obtained in processing block 1103. If a card insertion event is detected, 
processing path 1107 is taken lo processing block 1108 where the card 
insertion processing subfunction is activated for the newly installed card. 
Processing then terminates at return bubble 1131. 

Referring again to decision block 1105. if a card has not been 
inserted into a socket, processing path 1109 is taken to decision block 1111. 
If a card removal event is detected, processing path 1115 is taken lo 
processing block 1119 where the linked list of device driver stubs within 
device driver stub RAM area 505 is traversed in search of a device driver 
stub corresponding to ihe socket for the removed card. If a device driver 
stub corresponding to the removed card is found, processing path 1125 is 
taken to processing block 1 127 where a card insertion flag in the stub data 
, is reset to indicate that the corresponding card has been removed. Once the 
card insertion flag for the removed card has been reset, the device driver 
s.ub corresponding to the removed card is activated in processing block 
1129. Activation of the device driver stub corresponding to the removed 
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card causes the device driver stub to gracefully temiinate any ongoinE 
activity while the card was installed and disables further access to the 
removed card. The device driver stub is then unlinked from the linked list 
of device driver -stubs. Upon completion of processing block 1129, control 
5 is transferred back lo processing block 1119 where the stub linked list is 
again traversed for another device driver stub corresponding to the socket 
for which a card removal event was detected. The loop between processing 
blocks 1119 and 1129 continues for each device driver stub in the linked 
list until every device driver stub of the removed card is processed. When 
10 this occurs, processing path 11 23 is taken to bubble 1131 where processing 
for card event servicing terminates. 

Referring back to decision block 1 1 1 1, if the hardware event causing 
the activation of card event service routine 1 101. is neither a card insertion 
event nor a card removal event, processing path I ] 13 is taken lo processing 
15 block 1117 where the unidentified event is recorded. Processing then 
terminates at bubble 1 131. 

Referring now lo Figure 10, the card insertion processing 
subfunction 800 is illustrated. Card insertion processing 800 is activated 
either from processing block 715 illustrated in Figure 7 or processing 
20 block 1 108 illustrated in Figure 9. Card insertion processing 800 is 
responsible for controlling the allocation and loading of a device driver 
stub corresponding to a newly inserted feature card. Starting at processing 
block 801, the card memory area of the newly inserted card is accessed. If 
a device driver infonnation block (DDIB) is present in the card memory 
25 area of the newly installed card, processing path 805 is taken to processing 
block 807. If no DDIB is present in the card memory area, processing 
path 803 is taken to the bubble labelled C illustrated in Figure 12 where 
card insertion processing terminates at bubble 1017. Because not all 
feature cards require a device driver, processing path 803 is provided for 
30 those cards that do not require a device driver. 

At processing block 807, the header of the DDIB of the newly 
instalJed card is read. Decision block 809 tests whether or not the device 
driver stub for the newly installed card has been previously loaded based 
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on the device driver suib unique idcnlincaiion. If ihis device driver stub 
has been previously loaded, ihe device driver stub executable code does not 
need lo be loaded again. Thus, if ihe stub has already been previously 
loaded, processing palh 811 is laken lo decision block 821 where available 
5 space within device driver siub RAM area 505 is checked. If there is 
available RAM space for the device driver stub data and the stub header, 
processing path 825 is taken to the bubble labelled B as illustrated in Figure 
11. If, in decision block 821, there is not enough RAM space available, 
processing palh 823 is taken to processing block 824 where an error in 

10 driver lending processing is reported. Card insertion processing then 
lenninates through the bubble labelled C as illustrated in Figure 12. 

Referring again to decision block 809, if the device driver stub for 
the newly installed feature card has not been previously loaded, processing 
palh 813 is taken to decision block 815 where a lest is made to determine if 

15 there is enough space in device driver stub RAM area 505 for the storage 
of the device driver stub executable code, the device driver stub data, and 
the stub header. If there is enough RAM space available, processing path 
819 is laken to the bubble labelled B as illustrated in Figure 11. If, 
however, there is noi enough RAM space available as a result of the test 

20 made in decision block 815, processing palh 817 is taken to processing 
block 824 where an error in device driver loading processing is reported 
and processing tenninates through the bubble labelled C as illustrated in 
Figure 12. 

Referring now to Figure 11, card insenion processing continues at 
25 the bubble labelled B. At this point, it has been determined that sufficient 
space is available in device driver stub RAM area 505 for the storage of the 
device driver stub for the newly inserted feature card. In processing block 
827, a portion of the DDIB header from the newly installed card is copied 
into the preallocated device driver stub RAM area. In particular, fields 
30 41 1, 413, 415, 417. and 419 of the DDIB header are copied into fields 630, 
632, 634, 636, and 638 of the stub header, respectively. An additional 
portion of RAM in the device driver stub RAM area is reserved for device 
driver stub data in processing block 829. The size of this stub data area is 
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ai.<.uuicu V) d fW4incicrs^/ m inc uuio header. If the device driver stub 
was not previously loaded from a feature card or a list of preloaded device 
driver stubs loaded during bootstrap initialization of the computer system, 
processing path 911 is taken to processing block 913. In processing block 
5 913, the device driver stub executable code is copied from the newly 
installed fenture card to the preallocaied device driver stub RAM area 
within device driver stub RAM area 505. The strategy and interrupt 
offsets are loaded in processing block 915 to property reference the newly 
loaded code. Referring back to decision block 907. if the device driver 
10 stub was previously loaded from a prior feature card or an optional 
initialization preload list, processing path 909 is taken to processing block 
910 where the strategy and offset linkage is set to the previously loaded 
executable code. In this manner, loading a previously loaded device driver 
stub may be prevenied. Processing then continues at processing block 917. 
15 At processing block 917. the stub header area and stub data area 

within device driver stub RAM area 505 is initialized. Initialization of 
these areas includes loading linkage pointers, adapter and socket 
identification infomiation, and the device driver stub unique identification. 
Tliese areas may be loaded by transferring the corresponding information 
20 from the card resident DDIB header. A card insertion flag in the stub data 
is set in processing block 919 to indicate that the card is inserted into a 
socket and accessible to the computer system. Processing then continues at 
the bubble labelled E as illustrated in Figure 12. 

Referring now to Figure 12, the newly installed device driver stub is 
25 added to the linked list of device drivers maintained by the operating 
system in processing block 1001 . Adding the newly installed device driver 
stub to this linked list involves setting a pointer in the stub header to point 
to the next device driver block in the linked list. Similarly, the stub header 
pointer of the previous device driver block is set to point to the newly 
30 installed device driver stub. The device driver stub corresponding to the 
newly inserted card is activated in processing block 1009. As a result of 
the activation of the device driver stub, the device driver stub enables the 
activation of the full device driver code 309 resident on the newly installed 
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fully cxploiied. By executing ihc card resident full device driver, (he full 
device driver executable code does not need to be transferred to computer 
system random access memory for execution therein. 

Referring again to decision block 1204, if the device driver stub is 
5 not activated in response to a card insertion event, a card removal event is 
assumed. In this case, processing path 1205 is taken to processing block 
1218 where access to the card resident full device driver is disabled in 
response to the removal of the card. In this manner, computer system 
software is prevented from inadvertently attempting to access a removed 
10 card. 

Referring back to decision block 1203, if the device driver smb is 
not activated for the purpose of initializing the device driver stub, 
processing path 1205 is taken to decision block 1209. Processing path 1205 
is taken during the nonna! operation of the device driver stub after 
15 initialization has occurred. In this case, the presence of the card 
corresponding to the device driver stub is checked in processing block 
1209. If the card has been removed, processing path 1211 is taken to 
processing block 1217 where a device driver defined error is rcnimed and 
processing lenninates at bubble 1219. If. however, the card conesponding 
20 to the device driver stub is still present ancl active, processing path 1 213 is 
taken to processing block 1215 where a normal device driver request is 
serviced by the full card resident device driver. Upon completion of the 
normal request in processing block 1215. processing terminates at bubble 
1219. 

25 Tlius, a computer system having a method and means for 

dynamically configuring device drivers of system resources is described. 

Although the invention is described herein with reference to a 
specific embodiment, many modifications and variations therein will 
readily occur to those skilled in the art. Accordingly, all such variations 

30 and modifications are included within the intended scope of the present 
invention as defined by the following claims. 
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1 . In a computer system having a processor, a system memory, and an 
interface for receiving a removable system resource, a process for 
dynamically configuring device drivers of removable computer system 
resources, said process comprising the steps of: 

receiving an indication that a removable system resource has been 
coupled to said interface, said removable system resource having a 
resource memor>'. said resource memory containing device driver stub 
processing logic and full device driver processing logic; 

copying said device driver stub processing logic into said system 

memory; 

executing said device driver stub processing logic from said system 
memory; 

enabling access to said full device driver processing logic, said access 
being enabled by said device driver stub processing logic; and 

executing said full device driver processing logic from said resource 

memory. 

2. The process as claimed in Claim 1 wherein said resource memory 
further includes a device driver information block (DDIB) header, said 
process further including the step of copying said DDIB header into said 
system memory. 

3. The process as claimed in Claim 2 wherein said DDIB header includes 
link data and a device driver snib unique identification, said process further 
including the step of linking said device driver stub processing logic with 
different device driver stub processing logic stored in said system memory. 

4. The process as claimed in Claim 1 further including the steps of: 

determining whether said device driver stub processing logic already 
resides in said system memory: and 



providing a card insertion flag in said system memory; and 
selling said card insertion flag when said removable system resource 
is coupled to said interface. 

6. The process as claimed in Claim 1 wherein said step of enabling access 
to said full device driver processing logic further including the step of 
allowing memory mapping to said full device driver processing logic 
residing in said resource memory. 

7. The process as claimed in Claim 3 wherein said step of linking said 
device driver stub processing logic further including the steps of forward 
linking said device driver stub processing logic with different device driver 
stub processing logic and backward linking said device driver stub 
processing logic with different device driver stub processing logic. 

8. The process as claimed in Claim 1 further including the steps of: 

receiving an indication thai a removable system resource has been 
decoupled from said interface; and 

disabling access to said full device driver processing logic, said 
access being enabled by said device driver stub processing logic. 

9. The process as claimed in Claim 8 wherein said DDIB header includes 
link data and a device driver stub unique identincation, said process further 
including the step of unlinking said device driver stub processing logic 
from differem device driver stub processing logic stored in said system 
memory. 

10. The process as claimed in Claim 8 further including Ihe steps of: 

provfding a card insertion flag in said system memory; and 
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reselling said card insertion nag when said removable system 
resource is decoupled from said interface. 

11. In a computer system having a processor, a system memor>-, and an 
interface for receiving a removable system resource, a device for 
dynamically configuring device drivers of removable computer system 
resources, said device comprising: 

means for receiving an indication that a removable system resource 
has been coupled lo said interface, said removable system resource having a 
resource memory, said resource memory containing device driver stub 
processing logic and full device driver processing logic; 

means for copying said device driver stub processing logic into said 

system memory; 

means for executing said device driver stub processing logic from 

said system memory; 

means for enabling access to said full device driver processing logic, 
said access being enabled by said device driver stub processing logic; and 

means for executing said full device driver processing logic from 
said resource memory. 

12. The device as claimed in Claim 11 wherein said resource memory 
further includes a device driver infonnation block (DDIB) header, said 
device further including ihe means for copying said DDIB header into said 
system memory. 

13. The device as claimed in Claim 12 wherein said DDIB header includes 
link data and a device driver stub unique identincation. said device further 
including the means for linking said device driver stub processing logic 
with different device driver stub processing logic stored in said system 
memory. 



14. The device as claimed in Claim 1 1 further including: 



. .w. — « ""ig .laiu ucvikc uiivci aiuD processing 

logic already resides in said system memory; and 

means for preventing said copying step if said device driver stub 
processing logic already resides in said system memory. 

15. The device as claimed in Claim 11 further including: 

a card insertion flag in said system memory; and 
means for setting said card insenion flag when said removable 
system resource is coupled to said interface. 

16. The device as claimed in Claim II wherein said means for enabling 
access to said full device driver processing logic further including means 
for allowing memory mapping to said full device driver processing logic 
residing in said resource memory. 

17. The device as claimed in Claim 13 wherein said means for linking said 
device driver stub processing logic further including means for forward 
linking said device driver stub processing logic with different device driver 
stub processing logic and means for backward linking said device driver 
stub processing logic with different device driver stub processing logic. 

18. 'Hie device as claimed in Claim 11 further including: 

means for receiving an indication that a removable system resource 
has been decoupled from said interface; and 

means for disabling access to said full device driver processing logic, 
said access being enabled by said device driver stub processing logic. 

19. The device as claimed in Claim 18 wherein said DDIB header includes 
link data and a device driver stub unique identification, said device funher 
including the means for unlinking said device driver stub processing logic 
from different device driver stub processing logic stored in said system 
memory. 
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20. llie device as claimed in Claim 18 furiher including: 

a card insertion flag in said system memory; and 
means for reselling said card insertion flag when said removable 
system resource is decoupled from said interface. 

21. In a computer system having a processor, a system memory, and an 
interface for receiving a removable system resource, a process for 
dynamically configuring device drivers of removable computer system 
resources, substantially as hereinbefore described with reference to 
the acconpanying drawings. 

22. In a computer system having a processor, a system memory, and an 
interface for receiving a removable system resource, a device for 
dynamically configuring device drivers of removable computer system 
resources, substantially as hereinbefore described ^>'ith reference to 
the ccompanying drawings. 
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